Coaching  for  Better 


(Software)  Buying  Power  •  ;■ . 
in  an  Agile  World  * 


n  Nov.  13, 2012,  Under  Secretary  of  Defense  for  Acquisition,*Technology  and  Logistics 
Frank  Kendall  unveiled  his  guidance  for  improving  efficiency  and  productivity  under  the 
Better  Buying  Power  initiative.  Better  Buying  Power  2.0  (BBP  2.0)  identifies  36  initia¬ 
tives  under  seven  focus  areas  with  all  being  applicable  to  the  acquisition  of  software 
and  systems. 

The  extension  of  Better  Buying  Power,  coupled  with  ongoing  initiatives  to  improve  the  acquisition  of  information 
technology  (for  example,  Defense  Science  Board  2009,  Section  804  of  the  2010  Defense  Authorization  Act),  should 
lead  acquisition  professionals  carefully  to  consider  incorporation  of  agile  methodologies  into  the  set  of  acquisition 
tools  at  their  disposal.  This  transformation  is  not  easy.  It  requires  a  change  in  how  we  look  at  programs.  Therefore, 
DoD  should  consider  the  use  of  "Agile  Coaches"  to  assist  in  this  shift.  Ideally,  the  agile  coaching  corps  should  be 
internally  grown  and  assigned  to  acquisition  organizations  with  a  cadre  centrally  located  as  DAU  consultants  avail¬ 
able  to  support  any  and  all  acquisition  programs. 


Brown  has  more  than  20  years  of  defense  acquisition  experience  and  brings  both  the  contractor  and  government  perspective  to  his  cur¬ 
rent  role.  He  holds  both  Program  Management  Professional  (PMP)  and  Agile  Certified  Practitioner  (ACP)  certifications  from  the  Program 
Management  Institute. 
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This  transformation  is  not  eaTsy. 
It  requires  a  change  in  how  we^ 
look  at  programs.  Therefo^^ 

I 

I 

DoD  should  consider  the 
use  of  'Wgile  Coaches"  fo  • 
assist  in  this  shift. 


The  12  agile  principles  supporting  the  "Agile  Manifesto"  are 
closely  aligned  to  six  of  the  seven  focus  areas  of  BBP  2.0  as 
shown  in  the  following  paragraphs. 

Achieve  Affordable  Programs 

Agile  places  the  highest  priority  on  satisfying  the  customer 
through  early  and  continuous  delivery  of  valuable  software. 
Unlike  the  traditional  waterfall  method  that  delivers  at  the  end 
of  a  long  process  subject  to  schedule  delays  and  cost  over¬ 
runs,  the  agile  process  focuses  on  delivering  the  customer's 
top  priority  functionality  first  and  continuing  to  update  devel¬ 
opment  plans  so  that  the  customer  continuously  gets  what 
he  or  she  wants  the  most.  From  an  affordability  perspective, 
the  agile  process  stays  within  cost  and  schedule  constraints 
but  varies  the  features  delivered  within  those  constraints.  An 
agile  program  can  be  stopped  as  the  planned  funding  limits  or 
timeframes  are  reached,  and  the  customer  will  have  already 
received  the  most  valuable  set  of  capabilities. 

Cost  Controls  Throughout  the  Product  Life  Cycle 

In  addition  to  the  focus  on  satisfying  the  customer  described 
above,  three  additional  agile  principles  support  this  focus  area. 
Agile  methodologies  call  for  continuous  attention  to  technical 
excellence  and  good  design  to  enhance  agility.  Agile  under¬ 
stands  that  these  factors  cannot  be  completely  designed  up 
front.  Instead,  agile  processes  address  technical  excellence 
and  good  design  throughout  the  design,  development,  test, 
and  support  phases  of  the  product  life  cycle.  Agile  methods 
include  the  concept  of  technical  debt,  which,  simply  stated,  is 
the  increased  cost  of  change  due  to  poor,  inefficient  code  or 


due  to  the  backlog  of  unresolved  defects  allowed  in  the  sys¬ 
tem.  A  good  agile  team  will  plan  on  regular  refactoring  efforts 
to  ensure  that  the  software  conforms  to  high  standards.  Agile 
also  focuses  on  frequent  and  regular  delivery  of  functioning 
software  reflecting  top  user  priorities.  Therefore,  it  is  easy  to 
equate  costs  to  functionality  and  user  value  throughout  the 
development  process.  A  key  principle  of  agile  Is  simplicity,  de¬ 
fined  as  the  value  of  the  work  not  done.  The  concept  of  time¬ 
boxing  when  coupled  with  the  principle  of  simplicity  focuses 
agile  development  on  delivering  functionality  the  user  asks 
for— no  more,  no  less. 

Incentivize  Productivity  and  Innovation  in  Industry 
and  Government 

Agile  methodologies  support  the  close  alignment  between 
profitability  and  DoD  goals  through  the  frequent  delivery  of 
working  software  that  address  top  warfighter  priorities.  In  an 
agile  environment,  incentives  can  be  directly  tied  to  the  early 
and  regular  delivery  of  working  software.  Agile  also  focuses  on 
harnessing  change  for  the  customer's  advantage.  This  means 
that,  as  acquisition  professionals,  we  need  to  assess  how  and 
when  requirements  are  set  in  concrete.  This  also  means  we 
need  to  think  about  how  we  contract  for  capabilities.  In  an  agile 
world,  we  can  think  in  terms  of  fixed-price  or  fixed-price  incen¬ 
tive  contracts  if  we  fix  the  price  of  a  sprint  (using  an  agile  term 
for  a  short  duration  iteration)  then  buy  a  number  of  sprints 
as  an  option  if  the  contractor  meets  promised  velocity.  This 
strategy  allows  both  the  government  and  the  contractor  to 
be  responsive  to  changes  in  requirements  or  user  priorities. 

Eliminate  Unproductive  Processes  and 
Bureaucracy 

Agile  has  a  principle  called  simplicity  that  is  the  art  of  maximiz¬ 
ing  the  amount  of  work  not  done,  that  captures  the  essence 
of  this  focus  area.  Traditional  information  technology  acqui¬ 
sition  follows  a  sequential,  stovepiped  waterfall  process  that 
results  in  a  large  amount  of  "work  in  progress"  throughout 
the  development  effort  and  delays  delivery  of  functionality 
to  the  end  user  until  the  end  of  the  effort.  Agile  believes  that 
DevOps,  the  process  of  warfighters  and  developers  work¬ 
ing  together  throughout  the  project,  is  superior  to  volumes 
of  detailed  documentation  subject  to  misinterpretation— or 
worse,  nonuse— and  results  in  early  and  frequent  delivery  of 
the  capabilities  the  user  needs.  Simplicity  also  comes  into  play 
here  in  that  developers,  working  closely  with  warfighters,  can 
accurately  identify  when  a  capability  is  good  enough.  If  20 
percent  of  the  effort  can  deliver  80  percent  of  the  functionality 
and  the  warfighter  is  happy,  the  Department  is  better  served 
if  the  remaining  funds  are  allocated  where  they  can  address 
the  most  pressing  needs. 

Promote  Effective  Competition 

This  starts  with  establishing  the  government  as  the  product 
owner  and  ensuring  that  the  government  owns  the  functional 
and  technical  vision.  For  afloat  forces  in  the  Navy,  we  ex¬ 
pect  software  capabilities  to  ride  on  the  Consolidated  Afloat 
Networks  and  Enterprise  Services  (CANES)  infrastructure. 
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Contractors  follow  well-defined  software  development  stan¬ 
dards  designed  to  promote  interoperability  and  avoid  propri¬ 
etary  code  from  creeping  into  deployed  systems.  It  also  means 
the  government  program  offices  need  to  clearly  define  the 
desired  government  technical  data  rights. 

Improve  the  Professionalism  of  the  Total 
Acquisition  Workforce 

The  DoD  needs  to  invest  in  training  the  acquisition  workforce 
in  agile  methodologies  to  add  tools  that  can  be  used  effec¬ 
tively  when  appropriate.  The  Department  also  needs  to  look 
at  organizational  structures  and  relationships  that  promote  the 
values  identified  in  BBP  2.0.  Operational  commands  need  to 
understand  their  role  In  defining  priorities  and  working  with 
the  acquisition  agencies  to  ensure  their  voice  is  heard  through¬ 
out  the  development  process.  One  of  the  most  fundamental 
changes  is  in  how  the  Department  manages  requirements— or, 
as  they  are  referred  to  in  an  agile  environment,  features.  The 
incremental,  iterative  evolution  of  requirements  throughout 
the  life  of  a  project  calls  for  active  participation  instead  of  the 
frequent  practice  of  throwing  the  requirements  over  the  fence 
and  waiting  years  for  results.  Acquisition  professionals  need 
to  learn  how  to  manage  features  (large  blocks  of  functional¬ 
ity)  and  user  stories  (detailed  requirements)  instead  of  tasks. 
At  senior  levels,  we  need  to  think  about  how  we  manage  and 
assess  the  effectiveness  of  investment  strategies. 

In  the  preceding  paragraphs  I  discussed  how  agile  principles 
support  the  BBP  2.0  focus  areas.  Now  I  want  to  focus  on  the 
transformation  to  agile. 

The  first  question  always  is,  "Why?"  Version  One,  a  leading 
provider  of  tools  supporting  agile  development,  conducts 
an  annual  State  of  Agile  Survey.  The  results  for  2011,  based 
on  more  than  6,000  responses,  indicated  that  the  ability  to 
manage  changing  customer  priorities  (cited  on  84  percent  of 
respondents)  replaced  improved  productivity  (75  percent) 
as  the  leading  reason  to  be  agile.  Equally  surprising  was  the 
fact  that  project  visibility  (77  percent)  moved  into  the  second 
position,  indicating  that  senior  decision  makers  are  getting  the 
information  they  need  from  agile  projects. 

A  number  of  agile  programs  currently  are  being  executed 
within  the  DoD  environment.  The  DoD  even  has  a  draft 
Agile  Handbook  (Mitre  Technical  Report  100489)  that 
identifies  both  the  advantages  and  barriers  a  program 
faces  as  it  tries  to  adopt  agile  methodologies.  The  Govern¬ 
ment  Accountability  Office  (see  GAO  Report  12-681)  was 
asked  to  "Identify  (1)  effective  practices  in  applying  agile 
for  software  development  solutions  and,  (2)  federal  chal¬ 
lenges  in  implementing  Agile  development  techniques." 
Both  documents  contain  specific  recommendations  that 
address  key  reasons  agile  projects  fail  if  the  Department 
considers  moving  toward  increased  use  of  agile  software 
development  methodology.  The  2011  State  of  Agile  Survey 
reported  that  the  leading  causes  of  failure  for  agile  projects 
were  lack  of  experience  In  agile  methodologies  and  failure  to 


In  an  agile  world,  we  can 
think  in  terms  of  fixed-price 
or  fixed-price  incentive 
contracts  if  we  fix  the  price  of 
a  sprint  (using  an  agile  term 
for  a  short  duration  iteration) 
then  buy  a  number  of  sprints 
as  an  option  if  the  contractor 
meets  promised  velocity. 


understand/address  the  broader  organizational  Issues  in¬ 
volved.  These  top  two  were  followed  closely  by  corporate 
culture  issues  and  pressures  for  traditional  waterfall  methods. 

Agile  reflects  a  way  of  thinking  about  executing  projects 
that  cannot  be  learned  in  one  or  two  classes.  The  Defense 
Acquisition  University  (DAU)  is  continuously  improving  the 
Information  technology  curriculum.  The  challenge  will  be  to 
continually  raise  the  bar  as  agile  approaches  reach  deeper 
and  broader  into  the  national  defense  system.  DAU  also 
offers  coaching  services  but  the  number  of  agile  certified 
coaches  is  currently  limited.  These  are  valuable  resources. 
However,  software  development  organizations  should  con¬ 
sider  establishing  an  Internal  Agile  Coach  position  within 
the  acquisition  and/or  program  management  competency 
to  provide  the  ongoing  mentoring  and  advice  to  individual 
programs  considering  adopting  agile.  Both  of  the  previously 
referenced  documents  recommend  training  and  the  involve¬ 
ment  of  an  Agile  Coach  to  help  projects  and  organizations 
align  processes  and  organizational  structures  to  support 
agile  methods.  The  Agile  Coach  also  should  help  the  or¬ 
ganization  address  the  transition  from  traditional  waterfall 
processes  toward  increased  agility.  In  BBP  2.0,  Mr.  Kendall 
challenged  every  acquisition  professional  to  do  "more  with 
less."  Agile  methodologies  may  provide  the  means  for  us 
to  meet  that  challenge. 


The  author  can  be  contacted  at  martin. brownl^navy.mil. 
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